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Введение. Причины, побудившие нас к разработке ММ - это, с одной сто- 
роны, недостаточная выразительность для автоматической кодогенерации 
ТОЕЁ-нотаций, с другой — громоздкость стандарта УМЕ, на что обращено 
внимание, например, в работе [1]. 

Теоретические основы ММЁ описаны нами в статье [2], декларатив- 
ная состовляющая языка представлена в работе [3]. 

МУЕ предназначен для построения проектной диаграммы информа- 
ционной системы (ИС), из которой автоматически генерируется структура 
базы данных и программный код для вычисления расчетных данных. Авто- 
матическая генерация в таком случае позволяет: 

- не разрабатывать проектные артефакты, описывающие поведение 
и алгоритмы для программных объектов, реализующих бизнес-логику; 

- не писать вручную программный код для реализации бизнес- 
ЛОГИКИ; 

- автоматически поддерживать полное соответствие между проект- 
ными артефактами и программным кодом как в процессе разработки, так и 
во время эксплуатации системы. 

М\УЕ разработан так, чтобы для понимания проектной диаграммы и 
пользователи, и разработчики прикладывали минимальные усилия и тем 
самым могли проще находить общий язык. Для этого 

- проект программного обеспечения информационной системы вы- 
полняется только одной проектной диаграммой; 

- проектная диаграмма на уровне представления может разбиваться 
на любое количество субдиаграмм (подобно ЕК-диаграмме); 

- В диаграмме допускаются идентификаторы, образованные с по- 
мощью национальных алфавитов; 

- ММЕ прост и состоит всего из пяти визуальных элементов; 

- визуальные элементы М\УЁ аналогичны элементам из стандартов 
ОМЕ 2.2 [4] и ТРЕМХ [5] и поэтому интуитивно понятны не только разра- 
ботчикам ИС, но и опытным пользователям. 

При структурном подходе к проектированию ИС проектная диа- 
грамма на М№МЁ заменяет ЕВ-диаграммы, диаграммы потоков данных (ОЕО) и 
диаграммы деятельности (ТОЕРЗ), описывающие программный код. Проект- 
ная диаграмма может связываться с моделью бизнес-процессов через спе- 
цификации входов и выходов на диаграммах ТРЕРО. 
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При объектно-ориентированном подходе к созданию программного 

обеспечения ИС проектная диаграмма может заменить диаграммы реали- 
зации УМЕ для программного кода: классов (С!аз$ ГПладгат), кооперации 
(СоЙабогаНоп П’адгат) последовательности (5$едиепсе П’адгат), активности 
(Асимку Огадгат) и состояний (ЗаесНак Гладгат). 
Практическое использование визуально-декларированного языка 
М\УЕ. Прежде чем перейти к описанию языка, рассмотрим примеры его ис- 
пользования. Предметная область — организация выставок (упрощенный 
фрагмент). Компания на арендуемой территории проводит выставки, на 
которые в качестве экспонентов приглашаются юридические лица. Выстав- 
ка характеризуется названием и сроками проведения. Выставка с одним 
названием может проводиться с периодичностью раз или два в год. За 
проведение выставки отвечает менеджер — сотрудник компании. 

Экспонент подает заявку-договор на участие в выставке, где поми- 
мо собственных реквизитов указывает размер, расположение и тип арен- 
дуемого стенда (только одного). В зависимости от этих параметров рассчи- 
тывается сумма договора. Кроме того, в сумму договора входят обязатель- 
ный взнос и аккредитация представителей экспонента. Для иностранных 
участников наценка составляет 25%. Для участников, оформивших заявку 
за девяносто дней до начала выставки, скидка 10%. Помимо суммы дого- 
вора необходимо рассчитывать доходность выставок и количество заявок, с 
которыми работает каждый менеджер. 

Проектная диаграмма для данного примера представлена на рис.1. 
Сумма договора-заявки рассчитывается в атрибуте «Общ_Сумма» класса 
«Заявка», который зависит от атрибутов «Сумма», «Наценка» и «Скидка». 
Атрибут «Сумма» определен в этом же классе и складывается из стоимости 
стенда, обязательного взноса и суммы аккредитации. Атрибут «Скидка» 
определен в самом классе как равный нулю, но перекрыт в категории 
«Ранняя_заявка». Поэтому для экземпляров класса «Заявка», попадающих 
в эту категорию по условию, определенному в ней, «Скидка» рассчитыва- 
ется как 10%-ная от значения атрибута «Сумма». 

В условии категории «Ранняя заявка» используется функция 
Ти ау, которая вычисляет разность между датами в днях. Эта функция не 
встроена в язык или в стандартный набор функций системы управления 
базами данных, но М№МЁ позволяет использовать определенные программи- 
стами произвольные функции. 

Атрибут «Наценка» определен в категориях класса «Заявка», кото- 
рые образуют разбиение множества его экземпляров, поскольку связаны 
отношением исключения. Для экземпляров класса, попадающих в катего- 
рию «Зарубежная заявка» (по условию), «Наценка» рассчитывается по 
заданной в этой категории формуле. Для остальных экземпляров, попа- 
дающих в категорию «Отечественная_заявка» (по исключению), наценка 
равна нулю, как это в ней определено. 

Доход от выставки рассчитывается по суммам в договорах-заявках. 
Он определяется атрибутом «Доход» класса «Выставка» через ссылочные 
атрибуты «Стенды» и «Заявки», посредством которых можно получить дос- 
туп к атрибуту «Общ_Сумма» в свзязанных с каждой конкретной выставкой 
заявках. Эти ссылочные атрибуты неявно определены как обратные ссылки 
в классах «Выставка» и «Стенд» соответственно. Для образования обрат- 
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ных ссылок достаточно указать их имена в связи (после символа <->»). 
Функция 5ИМ является стандартным агрегатом, суммирующим все полу- 
ченные значения - в данном случае множества значений атрибута 
«Общ_Сумма» из связанных с выставкой заявок — для каждого экземпляра 
класса «Выставка». 

Количество заявок, с которыми работает каждый из менеджеров, 
рассчитывается в атрибуте «Число Заявок» класса «Сотрудник». Через 
ссылочный атрибут «Выставки» (неявно определенный как обратная ссыл- 
ка) осуществляется доступ к атрибуту «Открытые_заявки». Стандартная 
агрегатная функция СОУМТ подсчитывает количество значений этого атри- 
бута для каждого сотрудника. 

Атрибут «Открытые заявки» определен в категории класса «Вы- 
ставка», который с классом «Сотрудник» непосредственно не связан. Тем 
не менее доступ к нему обеспечен благодаря механизму наследования, ко- 
торый позволяет не только в классе-потомке непосредственно обращаться 
к атрибутам класса-предка, но и в классе-предке также непосредственно 
обращаться к атрибутам классов-потомков. Например, если нужно полу- 
чить список открытых на данный момент выставок (название, дата откры- 
тия, дата закрытия) на языке МОЕ [3], формулируется простой запрос: 

З@есЕ Название, Начало, Конец 

тготл Выставка 
м/пеге Сигепта{е Бе&мееп Начало апа Конец; 

Как видно, для атрибута «Название», хотя он и определен в другом 
классе, в запросе не надо делать никаких навигационных указаний -— сис- 
тема, исходя из проектной диаграммы, итак поймет, какое значение и от- 
куда нужно взять. Запрос можно сделать еще проще, если вспомнить, что в 
проектной диаграмме определена категория «Открытая_Выставка»: 

ЗеесЕ Название, Начало, Конец #гот Открытая_Выставка; 

В данном примере атрибут берется из класса-предка. В следующем 
примере продемонстрируем использование в запросах атрибутов классов- 
потомков. Как правило, осмысленные запросы требуют агрегации значений 
атрибутов, полученных из классов-потомков. Например, если надо узнать 
среднюю доходность по каждому виду выставок, можно выполнить запрос: 

З@есЕ Название, АУС(Доход) 

гот Вид_Выставки; 

Но иногда и без агрегации обращение к атрибутам потомков может 
быть вполне информативным. Например, мы хотим получить список контр- 
агентов, когда-либо принимавших участие в машиностроительных выстав- 
ках (допустим, название таких выставок начинаеся со слова «Машино- 
строение»): 

З@есЕ 41$ИтсЕ Стенды.Заявки.Экспонент.Название 

тготт Вид_Выставки 
м/пеге Название ЙКе `Машиностроение%’; 
Кстати, эквивалентным по результату будет запрос: 
З@есЕ 41$ЕтсЕ Название гот Клиент 
м/пеге ех!5{5 (Заявки.Стенд.Выставка.Название 
ИКе `Машиностроение%’); 


684 


Вестник ДГТУ, 2009. Т9. №4(43) 


Очевидно, что и планы выполнения, и стилистика двух последних 

запросов совершенно различны, что дает разработчику вполне приличное 
пространство для маневра. 
Последовательное описание М\МЁ. Основной элемент проектной диа- 
граммы -— класс. Семантика класса описана в [2]. В МУЁ класс представлен 
прямоугольником, состоящим из четырех горизонтальных секций (рис. 2). В 
верхней секции записывается уникальное имя класса и через двоеточие — 
его тип: СопсерЕ АБ$гасЕ Епт у или За. Тип класса характеризует при- 
роду его экземпляров (абстракции, сущности, состояния). У класса типа 
СопсерЕ есть только один неявный экземпляр (понятие). 


Имя класса: Тип класса Заявка: Епу 
Номер: уагеваг( 12) 


мя атрибута: тип атрибута Дата: Чае 

имя атрибута: тип атрибута Экспонент: Ех(Клиент) 

= Стенд: ЕхКСтенд) 

имя атрибута: тип атрибута Положение: Ех(Положение) 

мя атрибута = формула Стоим _Стенда = Стенд.Цена*Размер 

р (1+Положение.Наценка) 

имя атрибута = формула Сумма = Стоим Стенда + 
Стенд.Выставка.Взное + 
Участники*Стенд.Выставка.Аккредитация 

Скидка = 0 

Общ Сумма = Сумма - Скидка + Наценка 








спецификация метода 
спецификация метода 


спецификация метода 





а) 6) 


Рис.2. Классы в МГ: 
а — спецификация класса; 6 — пример класса 


Во второй сверху секции описываются исходные атрибуты. Задают- 
ся их имена и типы данных (домены) или экстенсионалы для ссылок. В 
третьей секции определяются формулы расчетных атрибутов. По исходным 
атрибутам автоматически генерируется схема базы данных, по расчетным — 
программный код, реализующий бизнес-логику. Четвертая секция предна- 
значена для спецификации методов. Описание атрибутов и методов вы- 
полняется согласно синтаксису декларативного языка МОЕ [3]. Имена атри- 
бутов и методов уникальны внутри класса, а также внутри ветви наследо- 
вания, за исключением случая явного перекрытия. 

Категория — множество экземпляров класса, соответствующих неко- 
торому логическому условию. Экземпляры класса задает пользователь. 
Множество экземпляров категории формируется автоматически из объек- 
тов, для которых условие категории в данный момент истинно. Категория 
изображается четырехугольником с закругленными углами, состоящим из 
четырех секций (рис.3). В первой секции записывается имя категории (мо- 
жет отсутствовать). Во второй секции задается логическое условие, опре- 
деляющее категорию. Третья и четвертая секции такие же, как в классе. 
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Имя категории Зарубежная заявка 


Экспонент.Страна.Название != 


Условие категории АОИ 
Наценка = (Сумма - Скидка) * 0.25 


имя атрибута = формула 
имя атрибута = формула 


ИМЯ атрибута = формула 


Конец <= Сите ае 
спецификация метода 


спецификация метода Открытые Заявки = Стенды.Заявки 
спецификация метода ыы 
а) 6) 
Рис.3. Категории в ММ: 
а — спецификация категории; 6 — примеры категории 





Между классами и категориями могут устанавливаться отношения 
трех типов. наследование, связь и исключение. 


Наследование обозначается стрелкой, направленной от потомка к пред- 
ку (рис.№). Формально семантика отношения определена нами в работе [2]. 


Вид_Выставки: АБзгасе 
Название: уагсВаг( 32) 
Менеджер: ЕхКСотрудник) 





Предок 


Начало: де 

Конец: 4ае 
Аккредитация: Сиггепсу 
Взнос: Ситепсу 


Потомок 
Конец <= Сипей же 


Открытые Заявки = Стенды.Заявки 


Открытая Выставка 


Начало => Сштепй же 


а) 
Рис.4. Наследование в ММГ: 
а — спецификация наследования; 6 — пример наследования 
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Основные следствия установления наследования между классами 
и/или категориями следующие: 

1. Отношение наследования является предпорядком. 

2. Потомок наследует от предка методы и атрибуты со всеми огра- 
ничениями. При этом методы и атрибуты в потомке могут дополняться и 
перекрываться. Исходные атрибуты могут перекрываться только за счет 
сужения области значений. Условия в категориях также могут переопреде- 
ляться только путем сужения области истинности в потомке. 

3. Каждый экземпляр класса-потомка связан отношением наследо- 
вания строго с одним экземпляром класса-предка. При этом значение каж- 
дого атрибута экземпляра-предка представляет собой объединение значе- 
ний соответствующих атрибутов его потомков. Таким образом, наследова- 
ние значений атрибутов происходит снизу вверх, а ограничений на значе- 
ния — сверху вниз. 

4. В классе (категории) непосредственно доступны все атрибуты, 
объявленные в нем самом, в его предках и в его потомках. 

5. Атрибуты и методы Сопсер{-класса неявно переопределяются (ста- 
новятся терминальными в смысле [2]) в его непосредственных потомках. 

С целью повышения качества проектирования на наследование 
введены ограничения, представленные в таблице. 


Ограничения наследования 


Объект 
Сопсер{- АБ гас(- Ейббу- За е- Категория 
класс класс класс класс 


+ 
Ейпбу-класс + 
ораке-класс | т о 
Категория П-ОВ ЗВЕНЕ ОНИ: ЗИ ЕЖЕ: ЗНИИНИЙ 


Отношение связи соответствует связи один-ко-многим или многие- 
ко-многим в реляционных базах данных. Устанавливается только между 
классами. Связь изображается сплошной прямой или ломаной линией с 
кружком на конце у подчиненного класса (рис.5). 


БЕ р НЕ: РЕНН 
Абяхтасеклас | + |+ 
о ош 











Имя прямой ссылки -> Юридическое Лицо: Сойс ерЁ 


т имя обратной ссылки Оо и 
Главный Подчиненный Название: уагсваг( 64) 


ИНН: спа 0) 





Страна: Её у 
Наименование: уагсваг( 32) 


Страна -> Клиенты 





Адрес: уатсваг( 128) 
Страна: ЕхКСтрана) 





Имя прямой ссылки -2 
Главный имя обратной ссылки | [одчиненный 








а) 6) 
Рис.5. Связи в ММ: а — спецификация; 6 — пример связи 
Если прямая ссылка может иметь несколько значений (случай мно- 


гие-ко-многим), кружок ставится с обоих концов линии. В этом случае вы- 
бор главного и подчиненного класса зависит только от предпочтений про- 
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ектировщика. Линия подписывается именами прямой и обратной ссылки, 
разделенными знаком «->». В подчиненном классе появляется явный ссы- 
лочный атрибут, через который происходит прямое связывание экземпля- 
ров подчиненного класса с экземплярами главного класса (внешний ключ). 
В главном классе при этом неявно образуется обратный атрибут-ссылка. 
Отношение исключения связывает два объекта и означает, что их 
экстенсионалы не пересекаются. На проектной диаграмме оно устанавли- 
вается только между категориями. На практике его удобно использовать 
как предложение ЕЁЗЕ по отношению к условию, определяющему связан- 
ную категорию. Например, категория Х определяется условием Б и связана 
с категорией У отношением исключения. Тогда категория У определяется 
условием поЁ Б. Исключение изображается сплошной линией (рис.6). 


Категория Категория Отечественная заявка Зарубежная заявка 


Экспонент.Страна.Название |= 





| ‘Россия 
Наценка =0 
Нана (Сумма - ду) *05 


а) 6) 
Рис.6. Исключение в №: а — спецификация; 6 — пример 


В предложенном примере проектная диаграмма (см.рис.1) позволя- 
ет продемонстрировать почти все особенности и возможности ММ. 

Рекурсивные вычисления разберем на примере другой упрощенной 
предметной области. Производственное предприятие выпускает изделия, 
состоящие из сборочных единиц. На изделия поступают заказы. Необходи- 
мо рассчитать подетальную плановую потребность (план) на каждую сбо- 
рочную единицу и ее стоимость с учетом стоимости составных частей. Оба 
атрибута вычисляются рекурсивно. Проектная диаграмма представлена на 
рис./. 


Сборочная_ Единица: Ей бу 


Код: сВаг(24) 

Название: уагсваг( 32) 
Собствен_Цена: Слитепсу 
Заказ: Пщесег 


План = бишт(Потребность) 





Узел -> Части 






Часть: За 


Узел: Ех{Сборочная Единица) р 


Количество: доцЫе Части 1$ Ми 






Стоимость = Собствен_ Цена + 


а = =( ‘обе 2 
Зша(Части.Стоим_в_Узле) Стоимость = Собствен_Цена 


Потребность = Количество * 
Узел.Потребность 


Стоим в_Узле = Стоимость * Количество 


Изделие 


Узел 1$ МИ 


Потребность = Заказ 


Рис./. Проектная диаграмма «Подетальное планирование» 
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Рекурсивные вычисления в общем случае выполняются, если: 

1. Имеется связь между двумя классами в одной ветви наследова- 
ния (в примере - это «Узел —> Части»). 

2. Вычисление производится с помощью определения рекурсивно- 
го атрибута минимум двумя формулами, одна из которых рекурсивна. При- 
меры рекурсивных атрибутов: «Потребность» и «Стоимость». 

3. Рекурсивная формула содержит конструкцию <ссылка на класс 
в ветви наследования>.<рекурсивный атрибут> или зависит от атрибута, 
формула которого имеет такую конструкцию. Пример первого случая -— 
формула атрибута «Потребность» в классе «Часть», второго — формула 
атрибута «Стоимость» в категории «Узел». 

4. Нерекурсивная формула должна быть определена в категории 

класса, в котором проводятся рекурсивные вычисления. В примере - это 
«Потребность» в категории «Изделие» и «Стоимость» в категории «Де- 
таль». 
Заключение. Разработана программная среда ТпоптаНоп бу$етз Беуе|- 
орег ЗУиаю (150$), которая позволяет строить проектные диаграммы на 
языке М№-\М5ца! Гапдчаде и автоматически генерирует схему базы данных и 
программный код для расчетных данных. Сейчас проводится тестирование 
этой среды на практических примерах. Предварительно можно сказать, что 
процесс проектирования и разработки в 150$ проходит намного проще, 
легче и дешевле, однако необходимо решать проблему оптимизации гене- 
рируемого кода. 
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